Still wonder whether to use View/Subview for that instead of Surface/Subsurface, since the Subsurface doesn't make much sense for people not familiar with Wayland.

Also not sure about the set_cursor API and it's not clear how Ids should generally work here. Like our WindowId should become some kind of Surface/ViewId and then when it comes to events surface/window/desktop is not well established throughout the API, so I'd probably hold a bit on that.

I'd also add a as_window(&self) -> Option<&dyn Window> on Surface trait to help with upcasting when passing just Surface around and raw-window-handle should be for Surface.

Still wonder whether to use View/Subview for that instead of Surface/Subsurface, since the Subsurface doesn't make much sense for people not familiar with Wayland.

I'll argue that Surface is used by graphics APIs and Wayland. I don't want this to devolve into bikeshedding, so I'll leave it as Surface unless the maintainers collectively agree that View is the better naming convention.

Also not sure about the set_cursor API

The set_cursor API is copied verbatim from the original window trait. It should be possible to have cursors per NSView; if not, that can be emulated by changing the cursor on PointerMoved events.

and it's not clear how Ids should generally work here. Like our WindowId should become some kind of Surface/ViewId and then when it comes to events surface/window/desktop is not well established throughout the API, so I'd probably hold a bit on that.

I already addressed event handling in my proposal. Summary:

• I agree with WindowId becoming SurfaceId.
• Pointer events can be received by any surface (window, popup, or subsurface), but keyboard events can only be received by windows.
• Events aren't bubbled. Not every platform does this, and the platforms that do should be able to stop them from being bubbled.

With the Windows commit, that's every platform I can test on my machine at the moment. I don't have a Mac nor do I have Android development set up at the moment.

Now that I'm assigned for review: I'd like this PR description and the resulting squashed commit to contain a description and justification of the respective changes, rather than merely mentioning that it addresses some part of a large discussion thread in an issue.

That should make it easier to review and backtrack.

Now that I'm assigned for review: I'd like this PR description and the resulting squashed commit to contain a description and justification of the respective changes, rather than merely mentioning that it addresses some part of a large discussion thread in an issue.

That should make it easier to review and backtrack.

I've updated the PR description.

Note to maintainers: I'm able to test Linux (X11 and Wayland) and Windows personally, but not any of the other platforms. As of now, I'm currently relying on CI to ensure the other platforms work (which given we don't have integration tests, I can't confirm they work). What should I do?

Given that PR should simply move code around it's unilkely to break things, unless you decide to do something fancy, though, PRs like that require approval from maintainers on the platforms you change stuff, so don't worry about it.

The implementation should be complete. Not sure why the formatting CI run failed, since I ran cargo fmt on my end already.

it requires nightly.

This should be ready for review now.

keyboard events can only be received by windows.

That's not correct on wayland.

That's not correct on wayland.

that's true, though not in the context of what winit has. Also, you can safely bubble them to ensure that all the platforms are consistent here.